Hi, here's some more progress to report. Again, I'll give a short summary and post the diary of updates.

Apart from continuing to make things thread-safe, I think the most interesting thing is a new system to make sure that a good part of the game code and data (the "Race" structure which holds Players and a lot of other data, for the game code) is not accessed by the graphics code, and also a smaller system to make sure the "Snapshot" (which is for rendering 3D and text) is not accessed by the game code. Considering that it would be quite impossible to find every line of code that is accessed in the wrong way, it's a great help to have these systems that can point out such issues whenever I come across them. It also helps me to devise more ways of restructuring the code to enforce thread safety.

Another interesting thing, at least to me is the live profiling graphs, which you can see in the attached images. LFS has always had one and it helps me to see which code uses a lot of CPU, (either because it's not well optimised or maybe there's a bug there). But it wasn't working recently due to the multithreading. I did have a CPU usage issue that forced me to sort out the multithreading version of the live profiler so I could track down the bug. Now I can select a profiler for the physics or graphics thread. The nice thing is these graphs are hierarchical, so I can click on the + buttons to see inside any section. I guess you'll know what I'm talking about if you have a look at the images. The first image shows the graphics thread CPU usage and the second image shows the physics thread CPU usage.

Here's the diary of updates:

6 Oct
Most of the day on home things (not LFS)
Afternoon / evening looked into the sound updates which can be improved
- in the most recent time graph you can see different length sound updates
- they are roughly in a 2:2:1 pattern, due to sounds being updated in 0.01s blocks
- it would be better to have variable length updates that can match frame lengths

7 Oct
Looked into sound improvements, changed the code to support variable length updates
- encountered various bugs, audio code is sometimes tricky to debug (due to timing)
- final bug was with the echo, realised there is a limit to the size of sound updates
- another obstacle I found is that the audio write point only moves in steps of 0.01s
- so it turns out I can't easily achieve the aim of variable length sound updates
- improvements have allowed me to split the sound updates over multiple physics frames
- another solution could be separate audio thread but it's too much work at the moment
Looked at FF rate - although 1000Hz is possible the options display still read 100Hz
Encountered (and fixed) thread-related crash when refreshing controllers in options
Fixed bug 'Flicker on car reset' which was thread related (wrongly reset draw values)

8 Oct
Morning with family
Looked into an issue where garage screen was initialised by game code when pitting
- that is against the rules of thread-safe behaviour in LFS code
- easily solved using a message from game code to main code to enter garage when safe
Found some bugs in Escape Menu - fixed them and improved the code for future proofing
Fixed thread-related and other minor issues with the Vehicle Editor
Moved position of "AutoJoin" which is for restarting autocross in multiplayer mode
Encountered a crash when second player joins race - related to drawing car alpha

9 Oct
Morning with family
Car alpha crash was due to removal of alpha LOD reset when car reset (bug fix 7 Oct)
- fixed by resetting alpha LOD to "do not draw" when car is created (not on reset)
Came up with another check to find code that is not thread-safe
- access "Race" structure (players, results, etc) through an access function
- this function can check that Race is only accessed from game code (not graphics)
- only trouble is the Race is accessed from around 900 lines of code... get started!
- stopped for the day after updating 400 of these lines to the new style access
- quick test already showed up two bugs for a quick fix and one more to note

10 Oct
Fixed yesterday evening's noted issue and carried on with converting Race references
Actually doing the changes makes me encounter various issues to fix along the way
It occurs to me that the Snapshot should also have the same type of protection as Race
- Race is for Game/Physics code and Snapshot (recently added system) is for graphics
Went ahead with restructuring Snapshot to an access protected version (fairly quick)
- Snapshot now contains a straight copy of the Race structure, excluding Players
- simplifies snapshot creation and makes it easier to convert code to use Snapshot
Stopped updating Race references for the day with only 164 remaining to deal with

11 Oct
Remaining references to Race have been updated to the new style after 2 hours
That is excluding some code related to skin resolution on the Misc Options screen
A race condition is revealed by the new check on switching from game setup to in-game
Also accesses to Race structure while drawing text in-game are revealed by the check
Fixed the text and entering game issues / made some changes to best lap announcement
MPR testing showed up bugs on restarting replay: crashes then invisible world issue
Clicking time bar at later point in replay is sometimes slow, sometimes fast
- learned how to reproduce the slow / fast versions of replay time clicking
- difficulty finding what extra processing takes place in the slow version
- built-in CPU profiler is currently unusable as it is not thread-safe
- looks like time to sort that out and that'll be another thing off the list
- profiler now selectable graphics / physics - used it to find the time clicking bug
Stop for the day, will fix "disappearing world on MPR restart" tomorrow

12 Oct
Fixed disappearing world on MPR restart - probably old bug unrelated to recent changes
- if layout objects were there, the occlusion octree was cleared when replay restarted
- needed to repopulate octree in that case - bug probably there since octree introduced
- for more info about the occlusion Octree see our September 2020 progress report
Back to fixing code that is not thread-safe (some identified by the new systems)
Garage was using (Player in) Race to decide which buttons to draw - now uses Snapshot
Spectate/Join wrongly used Snapshot copy of selected view (should use Game original)
Check for "Join reject" (first 12 seconds of race) needed Game and Snapshot versions
Something related to tyre warmers was called whenever a new Car was created in memory
Fixed that then spent a while cleaning up Car and Engine constructors for efficiency

More gradual progress to report. I don't think this is very interesting reading to most people but at least it shows the sort of thing I have to look into each day.

Attached an image of the updated timeline graph. It has some new colours. The reddish brown colour on the graphics thread is while it has called D3D 'Present' to apply the fully rendered image to the screen. It seems to take a long time to do that each frame because it is with Vertical Sync enabled, so it has to wait for the screen refresh (avoids tearing, and there is no point in having a higher frame rate than the monitor's refresh rate). But even during that time, the graphics card may still be rendering. The end of the blue part is only where LFS has finished sending draw instructions. The nice thing is that, with multithreading, that wait is no problem now, the physics updates keep going on as you can see.

Some gaps in the game/physics thread I believe are because my computer is so old it only has two cores (although it is a good, smooth running PC). I guess the operating system or another program wants to do something, so Windows gives a time slice to that other process instead of continuing with the LFS physics. I believe this might not happen much on a quad core.

Another thing is the audio code (yellow). Although better timed now, seems to take some time and bunch the physics updates. But this is the debug version of the code, it's a lot slower than the release build. So it might not be a problem at all.

Here's the diary of updates for any who are interested.

30 Sept
Graphical timeline showing what happens on the two threads over one second
- displays concurrency and shows where one thread can hold up the other
- reveals processing time differences between physics updates
- shows the bunching of physics updates by audio updates
- suggests better timing of audio updates

1 Oct
Timing investigation guided by the new graphical timeline
Improved accuracy of the system timer using undocumented ntdll functions
Improved the timeline a bit by adding new elements and adjusting exiting ones
Adjusted the timing of audio updates to avoid interference with the sync point

2 Oct
Adjusted game code to allow interruption of bunched physics updates for a sync point
Noticed that downloaded mods and skins are not reloaded in the best place (noted)
Made wait for sync point *always* interrupt overloaded physics (avoids visual hangs)
Noticed that game reset while physics objects moving calls D3D code 'illegally' (noted)

3 Oct
Investigating a known fault related to timer resetting when no guests are connected
Noticed some sync check values had not been updated for the 1000Hz physics update
Made some general improvements, simplified the timer reset code and fixed the bug
Moved reload of downloaded mods and cars with updated skins to the sync point
Fixed an already noted issue with auto restart on exiting the pits in hotlap mode

4 Oct
Spent some time looking at ways to delay the loading of textures when loading a car
- it would be better not do so any D3D work while loading a car but it's complicated
- some of the physics code (aero positions) depends on the 3D model being built
- possible solution is for the model to be built by game code but delay texture loading
Put that on the back burner for a while and looked at VR in the multithreading system
- found some issues including time appearing to slow down
- realised this is due to an oversight in the changes made on 2 August
- corrected that, continued VR testing, fixed a couple of bugs
Continued VR testing, looking at timing graph, experimenting

5 Oct
Another VR day, did research, testing, tried a different approach from yesterday
Ended up with good smooth results on tracks where my computer is fast enough
Did a substantial test on VR and FF wheel, driving at Bancroft and Fairfield
Force feedback can also be output at 1000 Hz with the physics updates
Seemed to feel higher resolution on the G27, I guess it could be good on DD wheel
Read through lists of things to do, would like to get a few crossed off tomorrow

Last edited by Scawen, Thu 6 Oct 2022, 07:24. Reason : not August... it's October - thanks Yisc[NL]

I've fixed that now and uploaded a C3 version.

It was a silly mistake where I had temporarily commented out some code for a test, but forgot to replace it after the test. Sorry about that!

I've adjusted the code so I can generate at different sizes.

So here is a zip file showing the current versions of:

South City (4096)
Fairfield Test Centre (4096)
Bancroft Autodrome (2048)

https://www.lfs.net/file_lfs.php?name=SO_FA_BA_bitmaps.zip

Hello Racers,

It is the 20th anniversary of Live for Speed becoming well known! According to various sources, it was on 18th August 2002 that Demo Test 0.04k first became known to more than a few people. It was very exciting to see the reaction to this new racing simulator that seemed to have appeared from nowhere and was quite different to what was available at the time. It had a focus on multiplayer racing. Despite synchronisation issues, it was already a lot of fun to race around Blackwood, with up to 8 drivers, in an XF GTI, XR GT, or XR GT TURBO.

If you'd like to try 0.04k it is available on our downloads archive page. It does not connect to the master server but it is possible to connect to a host directly by IP address.

LFS has come a long way since 2002, with 9 track areas now available and a huge variety of cars created by racers using the new mods system. Of course, there is more to come, notably a new graphics system and new tyre physics. The new graphics system includes dynamic lighting and day to night transitions. The tyre physics update is more realistic and accurate for a better driving experience.

We decided to show a few pictures of some track updates that Eric has been working on and share some technical details about the ongoing development in the physics system.

Please visit the 20th Anniversary page to see the screenshots, read about the development and watch a few short video clips.



Thank you for all the support over the last 20 years!

- LFS Developers

Hmm yeah as Flotch says, that is an old test patch.

Trouble is now as it has messed up some files I think you need to reinstall a fresh version 0.7D

I made a step forward in tyre physics last week. Although there is still a lot to do, I thought it would be good to try a test of the 1000Hz updates this week (nothing to do with tyre physics but may help with separating physics and graphics onto separate threads, along with other advantages). I was able to get a first version running in a day and worked another day searching through references to 'turns' and fixing various issues where the code had assumed that each turn was 0.01s. Now it's coded in a flexible way so I can change the update rate and recompile, to get comparisons between the 100Hz and 1000Hz versions. Actually there's a bit more searching to do but I was able to run some tests.

The good results:

The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...

This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.

That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.

With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.

Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.

Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.

The bad results:

So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.

Results when changing from 100Hz to 1000Hz:

10 cars on grid at new South City, physics code % of CPU time

environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40

What next:

The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.

The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.

Good question but the answer is quite unknown at the moment.

In fact it's not really 10 times the workload, although there is certainly more workload. The current LFS does 'subupdates' within the physics updates. The main reason for that is the wheel object suspended between a strong spring pushing down (suspension) and another stiff spring pushing up, the physics needed a higher update rate to avoid instability in that and I think on some other areas too.

In the public version that subupdate rate is 20 times the overall physics rate. So there is a part of the car already updating at 2000 Hz. In the development version there are 10 subupdates so it's already running at 1000 Hz.

But the ray checks vs world objects (and other cars) only happen at the base physics rate, so that is only at 100 Hz. This part might be 10 times the workload, as you suggest. There is also an advantage in the existing version that the subupdates are done as a tight loop on an individual car so I assume this is good for cache access. I'm sure that expanding the tight subupdate loop into full physics frame loops will be less efficient for cache hits.

Diagram:

Current:

0.00 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
0.01 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
[0.02s elapsed]

Proposed:

0.000 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
0.001 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
[0.002s elapsed]

I really can't guess how much more work this would be. The environment checks may be 10 times, as you pointed out. I think some optimisations might help with this. The subupdates shouldn't cost any more calculations but presumably will be slowed by memory access as the 'subupdates' are no longer done on a tight loop for a single car.

I think the way forward is to go through the program, adjusting it where necessary so that I can test the two scenarios above with a simple program change (update frequency & number of subupdates). Then test the CPU usage for the physics loop and see how it compares. That sounds simple but as you may imagine, I haven't always put in a suitable multiplier when trying to work quickly to release updates. There is some code around like "do this for 100 updates" which I knew would take 1 second. But now such code needs to be changed to the equivalent of "do this for 1/update_time updates" etc. It shouldn't take too long to get for a first test just to see how the CPU usage is affected. Hopefully it's just a search for the word "turns" and look at each one to see if it needs a fix.

The word "turns" (not case sensitive) appears 671 times
The word "Turn" (case sensitive) appears 785 times

Unfortunately the word "turn" in lower case is part of the word "return" which appears 9687 times. But don't worry, I should be able to devise reasonable strategies to find the relevant lines to check.

Last edited by Scawen, Sat 11 Jun 2022, 16:46.

Thank you for the tests.

I've uploaded a last chance test patch C6 as we plan to release the full version this afternoon.

Changes from C5 to C6:

Interface:

FIX: Virtual keyboard full of question marks in Greek or Cyrillic

List of events:

Lock icon reduces width of Join button to share the usual width
Generic 'play' character added for other live streaming services

That is now available in Test Patch C5:
https://www.lfs.net/forum/thread/98309

Changes in test patch C5:

List of events:

YouTube and Twitch links are now shown as icons instead of names
A lock icon is displayed beside Join button if password required

Mods screen:

Mod name was not always shown as selected when entering mods screen

Misc:

FIX: Corrected width of characters in text dialog code page view

Thanks for the report. I've now fixed this so it will be in the next test patch (after C4).

Thanks for the report. This is fixed in Test Patch C2:
https://www.lfs.net/forum/thread/98309

I've gone with the cyan version in test patch C4.

It's not implemented on the web side so you won't see anything yet.

The fix is available for testing in Test Patch C4: https://www.lfs.net/forum/thread/98309

OK I think I have a solution. Luckily I have an old FF joystick to test.

I tried your proposed fast fix: abs(nXForce) -> nXForce

But that doesn't work properly - it resulted in reverse force when steering left.

So I tried keeping the change you suggested but also set the direction to 'right' always. This seems to work.

CODE:

This seems to have the same result on the FF joystick and I guess it would work on your wheel.

That is fixed in Test Patch C3: https://www.lfs.net/forum/thread/98309

A crash fix and a few minor updates in Test Patch C3

For the keyboard steering with arrow keys bug, please try test patch C2:
https://www.lfs.net/forum/thread/98309

For the keyboard steering with arrow keys bug, please try test patch C2:
https://www.lfs.net/forum/thread/98309

NOTE: OFFICIAL VERSION 0.7D IS NOW AVAILABLE


WARNING: THIS IS A TEST

PLEASE TEST BEFORE YOU POST


Hello Racers,

Here is a new test patch: 0.7C6

The changes are listed below.

0.7C6 is COMPATIBLE with 0.7C

- You CAN connect online with 0.7C
- You CAN play replays from 0.7C

Please back up or rename your LFS.exe from 0.7C so you can revert to it if necessary.


Changes from 0.7C5 to 0.7C6:

Interface:

FIX: Virtual keyboard full of question marks in Greek or Cyrillic

List of events:

Lock icon reduces width of Join button to share the usual width
Generic 'play' character added for other live streaming services


Changes from 0.7C to 0.7C5:

List of events:

Time to live stream is displayed if it starts in less than 1 hour
Displays current and max connections on host if any are connected
Live stream service links are now shown as icons instead of names
A lock icon is displayed beside Join button if password required

Mods screen:

If host has a limited list of mods the filters are set to show all
Page Up / Page Down keys move a whole page (5 lines instead of 4)
FIX: Selected mod's name was not always identified as selected

Force feedback:

Change in force feedback code for devices that report two FF axes
- to fix a problem with some wheels with inverted FF turning left

Interface:

Click "Join" when no official cars allowed now enters mods screen
FIX: Crash after selecting a driver name from Join Specific Host
FIX: Assigned arrow keys adjusted brake balance (etc) while driving
FIX: Viewer button was available in garage during welcome sequence
FIX: Corrected width of characters in text dialog code page view


INSTALLATION:

A FULL version of LFS 0.7C must already be installed
To install the PATCH using the SELF EXTRACTING ARCHIVE:

1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way

NOTE: You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen: 0.7C6


DOWNLOAD:

PATCH 0.7C TO 0.7C6 (SELF EXTRACTING ARCHIVE) (If you already have 0.7C)
EDIT: Link removed, full version is now available (1.0 MB)

Last edited by Scawen, Fri 15 Apr 2022, 14:16.

Quote from ksa_land :

Found a minor UI bug. I installed fresh full 0.7C setup. After the licence agreement in the car/setup view I opened the viewer. Here, the UI of the viewer is overlapping the back/next buttons (see attached image).

Thanks for the report - I should disable the viewer button in the welcome sequence.

Quote from lucasazedo :

something went wrong in this patch. now it is no longer possible to race with Fbm, fox, f08 and any other car that has brake adjustment on the track, because whoever uses the arrows as a directional to guide the car is constantly lowering the % of the brake and stabilizer bar.

I can't see any difference between this version and version B regarding arrow keys adjustment of brake balance / and anti roll bar.

As I can't find anything from a quick test, can you tell me which version you go back to, to see a different result?

Last edited by Scawen, Sat 9 Apr 2022, 18:40.

Quote from Amynue :

Would it be hard to add a virtual mirror as a mapping? You know - a mirror which doesn't reflect the car model and only shows what's behind. Many modern vehicles have LCD screens as rearview mirrors, similar to backup cameras.

Well... it would be a lot easier than the current stereoscopic 3D mirror system! But it would be quite a system, with some new features like the ability to set camera positions and field of view, etc. I know a lot of people want this feature and I would like to do it, but it's another other of those things that is harder to do right now as all the changes would have to be done in both the current version and the development version. So at this point it's best to get on with the tyre physics so we can get back to a single version.


I've updated the editor to a new B12 version. It's a minor update - really just a test after merging all the recent LFS updates.

Text entry system language support was improved in LFS
Better alignment of entry screen buttons
Smaller LFS logo on entry screen

https://www.lfs.net/forum/thread/97865

Quote from Bzzyq :

The backgrounds behind the text could be less transparent

You can set that in Options... Display... Interface - Opacity (below 'Big Button' colour)


I've uploaded a new test patch B12, with minor updates. I've started looking into the tyre physics again. At this point I would like to release a full version with the latest changes from the test patches.

B12 has a fix and an option and all the recent changes have been fully merged with the development version. That is quite a big operation and always involves a few lines being changed, so it's worth testing. Also translations have been updated.

Command /eventlist=no to disable list of events
Corrected opacity of background buttons in mods screen
Can receive one more text field to show beside "Sign up"
Updated translations - thank you translators!

https://www.lfs.net/forum/thread/97772

Thanks, but please can you post that on the thread "How to improve attendance for scheduled events?" system as that would be on Victor's side, and I guess he might not follow this test patch thread.
https://www.lfs.net/forum/post/1996736#post1996736

What about if you could choose to receive an SMS about it? E.g. choose SMS and/or email notification?